Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

Database events

There are five database events you can associate with a trigger procedure:

CREATE — Executes when Progress executes a CREATE or INSERT statement for a database table, after the new database record is created. You can use the procedure to assign initial values to some of the table’s fields, such as a unique key value.
DELETE — Executes when Progress executes a DELETE statement for a database table, before the record is actually deleted. You can use the procedure to check for other related records that would prevent deletion of the current one, to delete those related records if you wish, or to adjust values in other records in other tables to reflect the delete.
WRITE — Executes when Progress changes the contents of a database record. More specifically, it occurs when a record is released, normally at the end of a transaction block, or when it is validated. This book recommends against using the field validation expressions that the Data Dictionary allows you to define because these have the effect of mixing validation logic with user interface procedures. The WRITE trigger happens in conjunction with those validations, if they exist, when the record is released or you execute an explicit VALIDATE statement. The WRITE trigger can replace those kinds of validations without combining validation with the UI.
ASSIGN — Monitors a single field rather than an entire database record, so you can use it to write field-level checks. An ASSIGN trigger executes at the end of a statement that assigns a new value to the field, after any necessary re-indexing. If a single ASSIGN statement (or UPDATE statement, but you know not to use that anymore) contains several field assignments, Progress fires all applicable ASSIGN triggers at the end of the statement. If any trigger fails, Progress undoes all the assignments in the statement.
FIND — Executes when Progress reads a record using a FIND or GET statement or a FOR EACH loop. A FIND trigger on a record executes only if the record first satisfies the full search condition on the table, as specified in the WHERE clause. FIND triggers do not fire in response to the CAN-FIND function. If a FIND trigger fails, Progress behaves as though the record has not met the search criteria. If the FIND is within a FOR EACH block, Progress simply proceeds to the next iteration of the block. Generally, you should not use FIND triggers. They are expensive—consider that you are executing a compiled procedure for every single record read from that table anywhere in your application. Also, they are typically used for security to provide a base level of filtering of records that the user should never see. For various reasons, including the fact that a CAN-FIND function does not execute the FIND trigger, this security mechanism is not terribly reliable. You are better off building a general-purpose filtering mechanism into your application architecture in a way that is appropriate for your application, rather than relying on the FIND trigger to enforce it.

There are also trigger events to support replication of data, so that any change to a database can be copied to another database. These REPLICATION-CREATE, REPLICATION-DELETE, and REPLICATION-WRITE events are described in OpenEdge Development: Progress 4GL Reference .